Many systems, such as control systems, monitoring systems, and the like, exist that allow discovery at runtime of devices active in the system. These systems may also discover a device's type thereby allowing basic control and monitoring with no external configuration. However, these systems depend on standardized application programming interfaces (APIs) describing Parameters, Properties, and Control Commands for different device types. Once a device of a known device type is found, the system can use a standardized API for the device type to control, configure, or monitor the device. For example, some of the attributes of security system device types include Properties, such as a manufacture and model, Parameters, such as arm-able state (ability to arm a system) and security state, (such as ARM_HOME, ARM, DISARM, and PANIC), and Commands (such as GetSecurityStatus, setSecurityState, and isOKToArm).
Unfortunately, many devices have capabilities that do not fit into standardized device type APIs. This particular trend is becoming more prevalent as manufacturers merge multiple capabilities into a single device, e.g., placing a DVD and a VCR in the same device housing.
Companies that support standardized device type APIs must frequently update their APIs to keep up with the latest innovations by device manufactures. This causes deployment issues as the control, monitoring, and integration systems that understand the APIs must be updated to understand devices using the latest APIs.
Many device protocols allow manufactures to add extensions to their device type API to allow the manufacturers to expose their devices' unique capabilities. However, custom code must then be developed and installed in the control or monitoring system to allow the system to utilize a device's extensions thereby requiring intimate knowledge of the control or monitoring system's internals. Additionally, custom code in a control or monitoring system hampers the ability to swap one device of a type for another of the same type. For example, custom code written for a receiver with custom capabilities will not perform when the receiver is swapped for one that does not have the custom capabilities.
Therefore, what is needed is a mechanism that overcomes the described problems and limitations.